Azure App Service で一意の既定のホスト名がプレビューで使えるようになっていたので試してみた
いわさです。
先日 Azure App Service を使おうとしていたところ、Web アプリの作成画面に「一意の既定のホスト名」というプレビュー機能が追加されていることに気が付きました。
そこで調べてみたところつぎの Azure 公式ブログが出ていることに気が付きまして、どうやら 2024 年 5 月ごろに登場した機能のようです。
例えば、App Service でアプリ名に「hoge0723app」と入力すると、デフォルト URL は「hoge0723app.azurewebsites.net」となります。
そのアプリを削除後に、同じアプリ名で作成し直すと、別の実体であるのもかかわらず同じデフォルト URL が使えるようになります。
有効化してみる
こちらのオプションを有効化してみましょう。
何やら URL にハッシュとリージョンコードが付与されました。どうやらこのハッシュコード生成をして URL に付与する部分を以て一意なの既定のホスト名と言っているようですね。
ハッシュコードは同じなのですが、リージョンを変更するとホスト名内のリージョンコード部分が切り替わります。
そのまま .NET 8 アプリをデプロイしました。発行された一意の既定のホスト名でアクセスすることが出来ました。
そして、このハッシュコードは別のアプリ名になると違うハッシュ値が割り当てられます。
ハッシュは再利用される
上記公式ブログに記載されているのですが、このハッシュ値は一定のスコープ内で同一アプリ名の場合に再利用されます。
Azure ポータル上から作成する場合は「テナント」がスコープとなり、同一テナント内で同じアプリ名で作成すると同じハッシュ値が再利用されます。
試してみましょう。
一度作成したアプリを削除し、同じ同じアプリ名で再作成します。
同じハッシュ値が再割り当てされましたね。こんな感じでスコープ内であればハッシュの再利用が出来るようです。
Azure ポータルの場合はテナントスコープ固定なのですが、API や ARM テンプレートから作成する場合はスコープ無しにしたり、あるいはサブスクリプションやリソースグループなどもスコープに設定出来るようです。
再生成された同一 URL でアクセスしてみましょう。
先ほどと異なり PHP アプリケーションをデプロイしてみました。
同じ URL で別のアプリケーションが表示されていることが確認できますね。
ちなみに今回は削除してから同一名で再作成したのですが、すでにアプリが存在する場合は作成することが出来ません。
スコープが異なればハッシュが異なるので同一名で再作成出来そうに思えたのですが、どうやらこれは、スコープが異なる場合でも再作成は出来ないようで失敗しました。
次は同一テナント内の別のサブスクリプション・リソースグループで、存在する同名アプリを作成しようとした場合のエラー発生状態です。
別のスコープでハッシュ値が変わるか確かめてみる
スコープの概念が理解出来たところで別のサブスクリプションや別のテナントで作成してみましょう。
同一テナントの別サブスクリプションの場合は、同じハッシュ値を確認することが出来ました。
そして、別のテナントで同じアプリ名だと異なるハッシュ値になりました。これはスコープが異なるからですね。なるほど。
さいごに
本日は Azure App Service で一意の既定のホスト名がプレビューで使えるようになっていたので試してみました。
これまであまり App Serivce の既定ドメインが使われてしまうケースを考えていなかったのですが、冒頭のブログに記載されているように乗っ取られるリスクに対処出来るとのこと。
既定のホスト名をそのまま使い続けることは多くないのかなと思いますし、CNAME で考えてもカスタムドメインを App Service 側で対応する必要があるかなぁと思っていたのですが、CDN オリジンで Host ヘッダーをオーバーライドする場合とかだと、確かに入れ替わりのリスクはあるのでしょうかね。